AWSのマルチアカウント戦略が難しい！

#AWS

#マルチアカウント戦略

川原征大

2022.07.07

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

今日(2022/07/07)は弊社、Classmethodの創立記念日ということで、 AWSのマルチアカウント戦略で思ったことをそのまま書き殴ってみました。共感するところや他に苦労しているところ思いついた方は Twitter 等で共有いただけると嬉しいです！

思いつく限り書いた結果の目次がこちらです。

「アカウントをどう分割するのか」問題
「AWS Control Tower を活用したほうがいいのか」問題
「ユーザー管理どうするのか」問題
「最小権限とは言っても」問題
「管理アカウントでの作業が怖い」問題
「OU/SCP周りの更新が怖い」問題
「セキュリティをどう向上するか」問題
「アカウント数のスケールにどう対応するのか」問題
「ベースラインの構築/管理をどうするか」問題
「ログ集約するのか/しないのか」問題
「どのアカウントかぱっと見て分からない」問題
「Security Hub のコントロールが増えすぎ」問題

(※1) 以降では「マルチアカウント戦略の推進をするチーム」を CCoE と呼んでいます。「CCoE とは？」という方は以下ブログを参照ください。

CCoEがやることについてまとめてみた | DevelopersIO

(※2) そもそもの「マルチアカウントとか Control Tower って何」的な話は↓にあります。

AWSのマルチアカウント戦略ってなに？なぜ必要？【社内勉強会スライド】 | DevelopersIO

「アカウントをどう分割するのか」問題

アカウント分割基準の明文化 が難しいです。

自分はよく↓のような「汎用的な回答」をしている気がします。

ステージ単位(STG, PRD等)で分割
- → セキュリティレベルやライフサイクルが違うため
システム単位で分割
- → サービス、リソースの干渉を避けるため
特定タスクのために分割(分離)
- → 集中管理のため (Control Tower の Audit, Log-Archive アカウントがこれに当たる)

ただ「システム単位ってなに？どの粒度？」と言われると回答に頭を悩ませます。「ライフサイクルが…云々」や「サービスとして独立している部分で…云々」といった文言だけでは、人によって解釈が違ってくるような気がします。明文化が難しい。

明文化にあたって、最低限「AWSアカウントの性質の理解」と「ワークロードに求められる要件の理解」は必須なのかなと感じています。

AWSアカウントの性質
- リソースの境界線
- セキュリティの境界線
- 請求の境界線
ワークロードに求められる要件
- サービス間の依存関係
- セキュリティレベルに違いがある要素
- サービスごとに関わる人(チーム)の違い
- コスト分析・比較を行いたい単位等

「AWS Control Tower を活用したほうがいいのか」問題

マルチアカウント環境を作っていくにあたって、「AWS Control Tower の利用はオススメ！」といった流れになりつつあります。ですが、現時点では必須ではないと感じています。 (AWS Organizations は便利なので有効化したいです)

Control Tower を有効化することで、ある程度整った Landing Zone からマルチアカウント環境を始められます。便利な点はもちろん多く、魅力的です。
Config や CloudTrail の設定がマネージドになったり、 Account Factory機能でアカウントベースラインを整えたりできます。昔は「OUの階層構造の制限」がありましたが、今ではそれは無くなったことも大きいです。

ただ、本番環境など「セキュリティをちゃんとやらないといけない環境」では、結局作り込むことになります。 Control Tower 提供のガードレールでは (現時点では) 不十分に感じます。予防的ガードレールであるSCPは、カスタムのものを作成して、アタッチするケースが多いです。発見的ガードレールとしてよく使われる Security Hubや GuardDuty は、Control Tower とは関係がないので、自前で有効化・チューニングを行います。

▼ 2023/01/05 追記

re:Invent 2022 にて Control Towerの大幅なガードレール拡充、および Security Hubとの一部連携がサポートされました！

「ユーザー管理どうするのか」問題

マルチアカウント環境において、ユーザー管理は課題です。シングルアカウントに比べて難易度が高いです。

「誰がどのアカウントにどの権限でアクセスできるか」の管理は煩雑になりがちですが、 CCoEとしてはちゃんと把握しておきたいです。よくあるアンチパターンは IAMユーザーを各アカウントに散らばらせることです。

認証と認可の設定は 1つの場所に集約させることを意識したいです。認証はユーザー情報、パスワードやアクセスキーのことです。認可は「ユーザーがどのアカウントにどの権限でアクセスできるか」の設定です。

例えば「IAMユーザーを集中管理するAWSアカウントを準備する」方法が候補にあがります。 IAMユーザーは集中管理して、それ以外のアカウントには原則スイッチロールでアクセスする方法です。また、Azure AD や Okta といった IDaaS や、AWS SSO(Single Sign-On)の活用も良いでしょう。

参考: マルチアカウントな AWS環境のマネジメントコンソールへのアクセス方法をまとめてみた | DevelopersIO

「最小権限とは言っても」問題

最小権限へのアプローチについては上記公式ブログによくまとまっています。

1アカウントだけであれば、こういったアプローチは良いと思います。ですがマルチアカウントにおいて「アカウントごとに最小権限を精査する」のは骨が折れそうです。 (もちろん全アカウントで行う必要は無いです。例えば非本番アカウントでは100点の最小権限は実装しなくても良い)

あと、IAM Access Analyzer は最小権限実現に使えるツールですが、今のところ上手い活用が想像できません。過去に使用したアクションから権限を作っていますが、「将来的に新しいアクションが必要になってたときの対応」を考えるとなかなか活用が難しい…ように感じます。

マルチアカウントの運用をしていて一番思うことは「IAMが分かる人をもっと増やしたい」な気がします。

「管理アカウントでの作業が怖い」問題

Organizations の管理アカウントは非常に権限が強いです。「SCPでアカウント単位で制御」ができたり、最近のアップデートで「アカウントの閉鎖」ができるようになったりしています。

そんな管理アカウント上に入って作業する…怖いですよね。

管理アカウント上の作業を減らすためにも、委任できるサービスはどんどん委任しちゃいます。よくあるものとしては、Security Hub や GuardDuty などのセキュリティ系のサービスでしょうか。また、最近になって AWS SSO も委任できるようになりました。ユーザー/アクセス管理で管理アカウントに入る必要が無くなる、嬉しいアップデートですね。

「OU/SCP周りの更新が怖い」問題

「OUによるアカウントの階層化」や、「SCPによる予防的ガードレール」は管理アカウント上で行う必要があります。これらの設定の影響範囲はアカウント単位です。正直怖いです。

SCPは「非本番OUへの適用」→「本番OUへの適用」と段階的に行うことで、影響範囲の精査ができるでしょう。

また、マネコン操作ではなく、IaC でこれら管理したい気持ちです。特に SCPは比較的長い行の JSONになりがちなので、差分やレビューを通すためにも特に管理したいです。残念ながら現時点では CloudFormation ではこれらは管理できないです。 Terraform では OU/SCP設定は対応しているので、利用すると良いでしょう。

▼ 2023/01/05 追記

ポリシー周りは委任できるようになりました！

AWS Organizationsのポリシー管理をメンバーアカウントに委任できるようになりました | DevelopersIO

▼ 2023/01/19 追記

OUやSCPもCloudFormationで管理できるようになっています！

AWS Organizationsの各種リソースをCloudFormationで管理できるようになりました | DevelopersIO

「セキュリティをどう向上するか」問題

アカウントが増えてくると、セキュリティ統制に苦労します。

各アカウントでセキュアに使ってもらうために、CCoEには色々な整備・推進が求められます。やることが多いです。例えば以下のようなことです。

ガイドライン
発見的ガードレール
予防的ガードレール
教育

ガイドラインを作成することで、AWSのセキュアな利用を指揮できます。ただしガイドラインを書いたからといって、開発者はそれを 100%守ってくれるわけではありません。人間なのでミスや見落としは起きます。セキュリティリスクのある構築やインシデントを起こすこともあります。

それに備えて、CCoEは各種ガードレールを敷く必要があります。例えば Security Hub を使うことでセキュリティリスクのある設定を検知できます。また、GuardDutyは不審なアクティビティを発見してくれます。 SCPを使うことで「そもそもリスクのあるアクションを起こさない」ようにできます。

あと、見落とされがちですが「AWS利用者のリテラシーを上げること(教育)」も大事です。 AWSリテラシーの向上はそのままセキュリティ向上に繋がります。

CCoEはそれぞれをバランス良く推進していく必要があります。やることが多いです。大変です。

「アカウント数のスケールにどう対応するのか」問題

マルチアカウント環境ではアカウント数はスケールしつづけます。それに対して CCoEの規模(人数) はスケールしないことが多いです。

そのため「各アカウントで起きている問題を、CCoEが個別対応」をしていると、 CCoEの負荷過多で破綻する未来が見えます。 CCoEはマルチアカウントを運営する「仕組みづくり」に専念できるようにしたいです。ベースラインやガードレール、ガイドラインといった「共通して設定/周知できる内容」を充実させたいです。

「ベースラインの構築/管理をどうするか」問題

アカウントのベースライン(セキュリティやネットワーク)の構築/管理で何を使うか。選択肢はたくさんあります。迷います。

ベースラインの内容・性質毎に使い分けるのが良いのは分かりますが、使い分けの感覚を掴みたいです。

比較的シンプルなベースラインで、どのアカウントにも自動展開させたいようなケースでは CloudFormation StackSet の OU自動デプロイで事足りる気がします。

アカウント跨ぎでリソースを構築していかないと行けないとき(TGWのクロスアカウント構築など)は CloudFormation では辛いと感じています。そういったときは Terraform の Multiple Provider Configurations を使うことで、解決できそうです。

それ以外の方法、AFTや CfCT、BLEAなどは触ったことが無いです。いつか触ってみて使用感を知りたいです。

▼ 2023/01/05 追記

re:Invent 2022 にてAccount Factory Customization (AFC)が利用可能になりました！

アカウントファクトリーからアカウントをカスタマイズできるAccount Factory Customization (AFC) が追加されました #reInvent | DevelopersIO

「ログ集約するのか/しないのか」問題

CCoEとしてどのログを「集約管理する」「集中管理しない」ははっきりさせておきたいです。それを決める基準が難しいです。

以下 3視点で考えると良さそう？と思っていますが、模索中です。

監査視点でログ集約しなければならないか
CCoE視点でログ集約したほうが良いか
- ベースライン(どのアカウントでも共通設定する)サービスのログは集約する
- アカウント横断でログを分析・比較したいときには集約する
開発者視点でログ集約 "しない" ほうが良いか
- 開発者としては、ログが他アカウントにあると不便。ログはすぐに、楽に見たい

「どのアカウントかぱっと見て分からない」問題

Security Hub 「 123456789012 で検知あったよ」
- → 私「 123456789012 ってどのアカウントだっけ…」
CFn StackSet 「 111111111111 と 222222222222 と 333333333333 にスタックインスタンスを展開してるよ」
- → 私「 111111111111 と 222222222222 と 333333333333 ってどのアカウントだっけ…」